Accretion

A collection of CDL circuits that together form a complete application. However, these circuits can be grouped into separate executable processes. Only when all of the processes are running is the application functionally complete. These processes may be run on any computer within a common network. Accretion is the mechanism of deciding which circuits are mapped to into which processes, to form the Colony.

Amdahl's Law

Gene Amdahl derived a formula that described the performance improvement of a computer program when it was optimized or distributed over a number of processors. This formula states that the benefit is reduced for each improvement/distribution and is fundamentally limited by the unimproved/undistributed part of the program. The law is typical of a 'Law of Diminishing Returns'.

Aperiodic Events

When events happen at regular/predictable intervals they are referred to as Periodic with the interval between the events referred to as the Period. However, when events happen at irregular/non-predictable intervals they are referred to as Aperiodic.

Arbitrated Store (Ast)

A CDL Arbitrated Store Object, holds data to be used by CLIP Methods etc. It differs from Transient Stores in that the data is persistent (ie it is not destroyed when it has been read) so that it can be re-read many times.

Asynchronous Events

When a number of events happen (or can be made to happen) at the same time, the events are said to be synchronous or synchronized. However, events that happen independently or cannot be made synchronous are said to be asynchronous.

Autonomous Process

When an accretion of CDL circuits are grouped into a single process, this single Autonomous Process provides the complete functionality of the application. Thus no additional executable processes are required or allowed. Since this process is comprised of one executable, it cannot be distributed over a network and must therefore run on a single processor. This is useful for development testing and basic debugging, by removing any potential problems of network timing etc.

Cache

A cache is a small (very fast) area of memory that is used to hold data that is currently being used, has recently been used or is predicted to be used. Ie if you where reading a book, it would be sensible to assume that if you're reading page 10, then you're likely to read page 11 next, or to look back at page 9. By 'guessing' what data to hold in the cache allows processors to perform at significantly faster rates than if they had to wait for data from the slow memory.

Every time a request is made for data held in the cache (cache hit) the computer guessed right, however every time requested details not in the cache (cache miss) the computer guessed wrong. Although manufacturers invest a lot of time and money into cache algorithms, programmers can do a lot to help, ie to access data in order (read page 1, 2, 3 etc).

Callback Function (Cbf)

A CDL Cbf Object is a simplified CDL Object Method, that is intended (and therefore restricted) to perform GUI specific functionality, when triggered by a CDL circuit event. To this end all Cbf are run in a dedicated system thread that handles all Cbf and GUI code. If an application has a GUI, then the message pump is typically executed by the main thread and so CBFs are generally applicable to GUIs. GUI code is very seldom thread-safe in general, and so this mechanism avoids the need for otherwise gratuitous use of locks.

Circuit (Cct)

A collection od CDL objects (and connections) that together form a complete logical solution to a part of an application. Multiple Circuits can be connected together as either child or peers, to build up the solution to the complete application.

Collector (Clx)

A CDL Collector Object, collects a number of events from other CDL Objects to form a compound event. The compound event is not propagated until all of the input events have been collected. There are two basic types of Collector: Random and Sequential. The random collector does not care what order the events happen, it will simply tick them off on its list, when they're all in it generates its output. Sequential collectors will collect their events in a predefined order. Events arriving out of order are ignored until the collector is ready to accept them.

Colony

Competer (Cpx)

A CDL Competer Object, allows other CDL Objects to compete for an event. Whereby the first object ready to receive the event gets it. Since most connections to CDL objects are inherently competed connections, Competers have the specialized role of enabling CDL objects to compete for events that are normally shared (ie events generated by CDL Distributors).

Concurrent

Events that can be processed independently and (where processing power allows) at the same time are described as concurrent. Regular concurrency describes the situation where the events are of the same form and thus will be processed in the same way and take the same time to process. This type of concurrency is easy to process using traditional programming techniques. Irregular concurrency describes the situation where the events are not similar, or need to be processed differently (or both) and hence take different lengths of time to process. Programming irregular concurrent problems is difficult using traditional programming techniques.

Concurrency Description Language (CDL)

CDL is a pictorial language for describing solutions to Irregular (and regular) concurrent programming problems. Each diagram in the CDL is referred to as a circuit diagram due to its resemblance to electrical circuit diagrams, with CDL objects connected together by 'wires' . This pictorial approach allows designers to concentrate on the functionality that must be performed and what is required before each event can occur. In this way the complex problems of scheduling the concurrent events, are solved simply by connecting the required CDL objects in the circuit diagram.

Conduit

A CDL Conduit Object is not a true CDL object in that it has no intrinsic behavior. It is simply a way of simplifying CDL circuit diagrams. A conduit is comparable to an electrical wiring loom. A number of colour coded wires (named connections) go in and each must come out. The conduit can be routed around a circuit without worrying about individual connections.

Consumer

CLIP is based on an event model, where events are generated by event providers and consumed by event consumers. CDL objects can be event providers, consumers or propagators an object consumes 1 or more events and provides 1 or more copies, or combined vents.

Counting Semaphore (Csm)

A CDL Counting Semaphore Object is a very simple object that maintains a counter. The counter is incremented every time it has been signalled and decremented every time it is read. The most common use of a semaphore is as a simple toggle (counter 0 or 1).

Definition (Object)

An Object Definition describes what the object is and how it interacts with other objects. It is used by the code compilers to create Instances of the object. Objects dont exist until an Instance is created.

De-Multiplexor (Dmx)

A CDL De-Multiplexor Object divides a multiplexed stream of events back into separate named channels. Each named output channel must match a corresponding named multiplexed channel.

Device (Dev)

A CDL device is not a true object. It is a means of interacting with something else, usually an non-CLiP object. The term derives from the first (and most common) non-CLiP objects that where interfaced, hardware devices. The CDL devices were written as extensions to the hardware 'device drivers', to provide a common hardware independent abstract interface. This is still the case except that the notion of devices has been extended to cover anything outside of CLIP control that has its own blocking mechanism eg. File Systems, Operating System calls, Sound/Video hardware, Networks etc. Abstracting the device interface allows the CLIP application to access the device in a standardised way. Should the device change then only the device code needs to be modified (eg. an application that wishes to generate log files, does not care whether the recording device is a hard disk, a tape recorder, a optical disk).

Distributer (Dbx)

A CDL Distributer Object consumes events from a single source and copies (distributes) each event to all consumer objects that have registered an interest.

Dynamic Recruitment

Dynamic recruitment allows a system to start, even when there is insufficient processing power available (albeit with a reduced capability or performance). Dynamically added or removing 'slave' processing power whilst the system is running will simply improve or reduce the overall capability or performance.

Event Processing

CLIP is based on an event model, where events are generated by event providers and consumed by event consumers. CDL objects can be event providers, consumers or propagators where an object both consumes and provides events. Events describe the state of the object that has generated it. Compound events are a collection of events from multiple providers that have been combined to form a single event.

At the heart of the event mechanism is the data stores and methods. The events provided by store objects show whether a store is free to be written to or can be read from. These events are ultimately consumed by methods which can either read from a store, or write to it, depending on the store's state described in the event. Thus 'event flow' around a circuit can be in either the same direction or the opposite direction to conventional 'data flow'. Since a compound event can contain both a 'ready for write' state event and a 'ready for read' state event, 'event flow' can be both 'with' and 'against' the 'data flow' at the same time.

By processing events rather than data, CLIP reduces the system over heads required by only moving the data when it is necessary.

Garbage Collection

Many programming languages permit programs to allocate memory from the heap and to free it again at some point later. This has traditionally led to many software problems where, programmers have forgotten to free the memory or tried to reuse it after it has been freed.

A number of modern languages (Ada, C#) try to overcome these problems by managing memory deallocations automatically, deleting the memory when there are no longer any references to it. The garbage collector can also run in the background, deleting the memory at a more convenient time.

Graphical User Interface (GUI)

Although there are technical differences between GUI's, HCI's and MMI's, this documentation will use the 3 indeterminately, to refer to the generic mechanism whereby a user interacts with an application via a mouse, keyboard or speech, to move a screen pointer to operate a feature on the screen to effect the application output.

Holographic/Holistic Processing

Holographic processing or Holistic processing is a programming technique where the whole application is contained in all parts of the application. Thus any part is capable of performing all/any part. This is distinct from traditional 'Modular' programming where an application is divided into modules, each only capable of performing its specific task. This traditional approach requires each module to be individually maintained and thus introduces the problems of incompatible modules getting out into the field. In holographic processing there is only one version of the software, thus only one version to maintain and no possibility of incompatible modules. It also means that the system can be speeded up by simply running more copies of the application, whereas modular programs can only be speeded up by improving the performance of each and every module.

Human Computer Interface (HCI)

Although there are technical differences between GUI's, HCI's and MMI's, this documentation will use the 3 indeterminately, to refer to the generic mechanism where a user interacts with an application via a mouse, keyboard or speech, to move a screen pointer to operate a feature on the screen to effect the application output.

Hybrid Diagram Development

Hybrid Diagram Development is a cross between, fully auto-generated code development from diagrams and hand written code. Both Microsoft Windows Visual Studio and Blueprint use a Hybrid approach, where you draw part of the application using a toolbox of objects. Many properties/ basic behaviour can be modified by simply selecting options from the Object properties window. Any additional behaviour can then be hand coded by opening a code window for that object.

Instance (Object)

An Object Instance is created from an Object definition. Each instance must have a unique Name. Once created memory is allocated on the stack or heap. Objects cannot be accessed unless an instance exists.

Eg. Int i

where Int is an object definition and i is an instance of that definition and will be referred to as i.

Interface (Ifce)

A CDL Interface allows non-CLiP code to access CLIP objects via the Objects Connection prototypes. Interfaces can be extended to hide the logic of the application from the interface user. E.g. a GUI programmer does not need to know how the system works or what state it is in, only whether a button should be enabled or not.

Job

Scheduling tasks for execution involves the insertion of tokens into queues. These tokens describe the task entry point, as well as references to inputs and outputs, and are referred to as 'jobs'. The scheduler therefore provides jobs to system owned worker threads that then execute their specified tasks. In the case of slaveable methods (see Colonies), only the job token and the data that it references needs to be sent to the slave because the translator will ensure that the method code is linked in to the slave build so that it can be executed as a local task.

Latency

Latency is the time difference between a task being initiated and its result being returned. This is usually longer than the time taken to execute the task, as many things can happen between the task being initiated and it starting, and it ending and its result being returned. Latency has two main causes: raw CPU performance and running multiple tasks or sub-tasks, where each task/sub-task has to wait for system resources. Task Latency can be reduced by careful design to reduce the number of tasks left waiting for others to complete.

Logical Semaphore (LSM)

A CDL Logical Semaphore is similar to a CDL Counting Semaphore, except for one significant difference. The state of the semaphore is not modified when it is read. Thus once set it will remain set until it is explicitly unset. When reading a Logical Semaphore, a number of rules can be applied. Eg is the current value 'equal' to the desired value.

Man-Machine Interface (MMI)

Method (Mthd)

A CDL Method Object is a simple processing unit. When all of its requires inputs and outputs are ready, it is queued ready to run on the next available processing resource and given access to all of the data inputs and outputs that it requires. It is never scheduled unless all of its inputs/outputs are ready, thus there is no need for the Method code to check their status.

Methods, unlike Threads have a simple purpose, they perform that task then stop and await to be rescheduled.

Middleware

Middleware is a software layer between an application and the hardware/operating system. This allows an application to be written that knows nothing about the eventual platform that is will be run on. The middleware provides a single set of functions that translate the applications requirements into the actual hardware/operating system requirements. Since this would be a huge task for every hardware/operating system capability, most middlewares concentrate of specific areas of interest

Eg.

DirectX - graphics

OpenMP - inter-processor communications

CDL - inter-process communications

Message Passing Interface (MPI)

There are a number of ways of communicating between processes running in a application, eg. Shared Memory, Messages. The former is only possible when both processes are co-located and such that they can both see the memory. The later can be used with either co-located processes or remote processes that dont share memory and utilises a network protocol (eg. TCP/IP) to pass messages containing the required information from one process to another. To hide the complexities of the underlying network protocol and handshaking rules, a Message Passing Interface abstraction layer is used. However, MPI's have both a memory and process overhead, which are expensive if the processes are co-located.

Multiplexed

Multiplexing is a means of passing information from several sources to a single receiver. The information sent by each source may have a similar format or could be completely different. There are a number of basic approaches Round-Robin, Prioritised and Time-domain.

Round-Robin multiplexing takes incoming data events and sends them onto the receiver in what ever order they arrive. Thus the receiver can get any data from any source in any order, and must deal with each appropriately.

Prioritised multiplexing chooses which source to send next based on a prioritisation rule. The receiver still has to process any packet from any source, but more important information is processed first.

Time-domain multiplexing uses an output block that has slots for each of the possible inputs, but only fills those that have been received (within a specified interval). This results in a larger output packet but simplifies the receiver processing. Time-domain multiplexing is usually restricted to very small data packets, where the multiplexing overhead would be larger than the data packet. Thus sending 1 larger packet is more efficient than sending several small packets even if many are empty.

Multiplexor (Mpx)

A CDL Multiplexor Object takes events from a number of independent input streams and passes them out (in order) on a single output stream. A multiplexor is deemed overloaded if the events on the input streams have different structures. A CDL Multiplexor can use either Round-Robin or Prioritised multiplexing.

Multi-Core Processing

Multi-core Processing is a relatively new term, since processor manufacturers have managed to place two or more processors on the same chip, so that they can share memory and cache resources. Each core is a separate entity and runs one or more threads (tasks). A thread cannot be shared between cores, but it can be moved from one to another by the operating system. Thus an application that only uses a single thread (most legacy applications) can only run on a single core no matter how many there are on the processor chip and so will not run any faster (in practise it will run slower as more multi-core processors use less powerful cores than a single core processor).

When running a multi-threaded application on a multi-core processor, performance can be seriously degraded if the threads are accessing the same memory areas as the operating system has to ensure that the local caches for each core are kept in sync, effectively stopping each affected core as it does so.

Multi-Threaded Processing

Multi-threaded processing is means of breaking down an application into chunks that can be processed independently. Each chunk is processed by a thread. When a processor has more threads than cores, it divides each thread into a series of time-slices, and process each slice in turn, rotating through each of the threads. Each time the processing steps from one thread to the next there is a 'context switch', where the operating system has to save all of the current thread's registry, stack pointers, code pointers etc and reload in the next threads data before continuing. More threads means more context switches and a reduction in performance.

In practise threads are rarely independent, they may execute for long stretches independently, but they often have to wait for another thread to complete an action before continuing, or require require access to some common data or resource. To prevent data corruption or deadlocks, these synchronisation points must be carefully managed. Good thread synchronisation is also essential to obtain good system performance (minimal time spent waiting for other threads). This is usually achieved through small well-defined threads that have a dedicated task. However, more threads means even more synchronising.

With modern multi-core processors, it is now possible to genuinely run threads in parallel rather than the time-sliced pseudo parallel single core processing. This has exposed a number of issues in legacy code where sequential thread operation was implicitly assumed. True asynchronous thread synchronisation is an art form that means using traditional thread synchronisation mechanisms is a mine-field for beginners (and experienced) programmers, which gets worse as the number of threads increases. The recent development of TBB, TPL, CILK and CDL try to simplify these synchronisation issues and allow programmers to develop true multi-threaded, multi-core capable applications.

Mutex

Mutexes are simply a set of flags that are globally defined. These flags are used to restrict access to certain areas of data or code. To gain access a thread must first obtain the relevant mutex, if it is not available the thread is added to a queue and blocked. When a thread finishes accessing the data/code it returns the mutex, whereby the next waiting thread is woken and granted the mutex.

Since mutexes are so simple they are often over-used. This causes many problems in applications; threads blocking when they could be doing something, mutexes being handled to inappropriate threads, etc. Although Mutexes are simple their usage is a complex art form, ie prioritized queues, read-write mutexes (only one thread can hold a write mutex but several can hold a read mutex but not at the same time as a write mutex is held by a thread, or visa-versa).

Use of mutexes should be restricted to specialized code sections.

Object-Oriented Programming (OOP)

Object-oriented programming (OOP) is a programming paradigm that uses "objects" and their interactions to design applications, rather than the older 'task (function/subroutine)' based applications, where a task called other tasks (in a predefined order) in order to complete its task (the application is the primary task). OOP objects communicate with other objects, each has its own private data and set of tasks that can be requested. So rather than passing some data to a function to say print it, we would call on the data object to print itself.

This has the advantage that the data object print task only needs to know about how that object is to be printed. In the task based programming the print task needs to know about every data type and how it needs to be printed. Any changes to the data require changes to lots of tasks. In an OOP changes to the data only need to be reflected in the data objects internal tasks.

OOP techniques also include features such as:

encapsulation - hiding internal data from everybody else

modularity - defining objects to have small dedicated features

polymorphism - an object not needing to know what it is until the last moment E.g. we may know "we need to print something", but we dont actually need to know "how to print" until we know "what to print"

inheritance - an object definition is based on a existing more general definition providing some basic capabilities. Multiple inheritance, an object is based on two or more base objects.

Ball : an object used in ball games

Round ball : a spherical ball

Rubber ball : a ball made of rubber

Squash ball : a round+rubber ball approximately 4cm in diameter used in the game Squash

A full treatise on the definition of OOP is outside the scope of this glossary. The author suggests the reader view some of the many excellent books and web-pages available on OOP.

OpenMP

OpenMP is a public API for a Message Passing Interface.

Process

A process refers to a single executing instance of a program executable. A process may have multiple threads of execution, and in most cases (e.g. SMP architectures) the process can utilize more than one processor/processing-core simultaneously.

Prototype

A CDL connection Prototype is an interface contract between CDL circuits. A prototype has two flavours Providing and Consuming. A Providing Prototype is generated from a circuit providing access to its objects, whilst a Consuming Prototype specifies what a circuit is expecting to see.

A valid connection between two circuits can only be created if the Consuming Prototype has the same logical structure as the Providing Prototype. Ie object names are ignored, but object types and data types must match.

Provider

Record

A Record is a CLIP handler Object for managing user data classes held in CLIP stores. In this way CLIP needs no knowledge of the user data, and the user data needs no knowledge of the access locking, data sharing or data transferring etc, which is all handled transparently by the CLIP Record.

A CLIP record provides a number of functions that must be implemented by the user data class: Size() and Initialise(), as CLIP will call these on the Record which will in turn pass them onto the data class. All other access to the user data is via the Records Data() or Struct() functions.

Recursion

Recursion is a process whereby a function calls itself.

Care should be taken when generating recursive calls as it is easy to generate an infinite loop. Recursive functions should either recurse on entry or exit, they should not 'do something, call themselves, then do something else' and there must always be a condition which doesn't recurse.

int recurse_on_entry( int x )
{
   // pass the value down, do the multiplication on the way back
   if ( x > 0 )
      return x * recurse_on_entry( x - 1 );
   else
      return 1;
}

int recurse_on_exit( int x, int mult )
{
   // do the multiplication on the way down, dont do anything on the way back
   if ( x > 1 )
   {
      mult *= x;
      return recurse_on_exit( x-1, mult );
   }
   else
      return mult;
}

Reducer (Rdx)

A CDL Reducer Object, reduces the number of events flowing through the system by consuming events at a specified rate rather than passing them on. Both the rate and the phase can be dynamically set. A rate of 3 will pass on 1 event in 3, whilst a phase of 3 will pass on the third of the 3 events rather than the first or second.

Reentrancy

In a multi-threaded application, each thread is allocated slices of time in which to run. At the end of each slice, processor resources are handed to the next thread ready to be executed. Since the handling of time-slices is abrupt (threads stop immediately at the end of the slice, they are not allowed to finish what they are doing) it is possible for two or more threads to be executing copies of the same code.

When functions are written with this in mind they are said to be Reentrant (ie they are safe to be entered more than once) or Thread-Safe.

Problems often occur when code is not Reentrant, this happens when the code accesses data (memory) that is globally defined, and then gets interrupted (end of time-slice) by another thread that then resets the data. When the first resumes, the value has changed and any actions taken based on the old value will be erroneous. Quite often the non-reentrant code is hidden in another (system) function, lying in wait for the unsuspecting user.

Any function that contains any functions whose reentrancy is not-known must be considered non-reentrant.

To enable a reentrant function to access global data, the data must be protected by Read-Write Mutexes and code 'Critical Sections'. These restrict access to the data between certain code points to a single thread, and no other thread is allowed to enter the Critical Section until the previous thread has exited and passed on the relevant mutex.

Reference

References are similar to instances, in that the object exists. However, a reference is an alternative way of accessing an instance of another object. When an instance is passed around a system, the whole memory allocation for that object is passed. However, when moving a reference only sufficient information (ie the instance objects location) for the system to maintain the connection back to the original instance needs to be moved.

CDL references refer to objects that exist in other circuits. They may even exist outside of the current application. As long as its full registered name is known and there is a network connection between, the actual instance can be located. The object can then be accessed via its published connection prototype.

Semaphore

A semaphore is a simple mechanism for transferring simple state information between objects. Unlike stores semaphores hold no other information.

CDL provides two types of semaphores

Counting semaphore - holds a simple counter which is incremented whenever it is signalled, and decremented whenever it is read. An object requesting a read when the counter is 0, will block until the counter is incremented to at least 1. A counting semaphore can be used like a padlock with only 1 key. As long as you have the key you have access to whatever the padlock is protecting.

Logical semaphore - holds a simple value, which can be set to any value by a signaler. The value is not modified by readers, it is held until it is reset to a new value. Readers will block if the current value does not match the readers request. Read requests can include a specific value or a range of values. A logical semaphore is comparable to a combination lock, as long as you know the combination you can get access. By changing the combination you can modify who has access.

Symmetric Multi-Processor

An SMP is a computer-architecture where two or more identical processors can connect to and share a single physical memory. SMP architectures can contain separate processors using motherboard bus to access the memory or a multi-core processor, where the processors are on the same silicon or a combination of both. (Current 8-way processors actually use two 4-core processors) However, the distinction is handled by the hardware and the operating system.

SMP systems allow any processor to work on any task no matter where the data for that task is located in memory; with proper operating system support, SMP systems can easily move tasks between processors to balance the workload. However, operating systems cannot arbitrarily split a task between processors.

Splitter (Spx)

A CDL Splitter object, undoes the event combining performed by a CDL Collector. It allows circuits to force a synchronisation point (the collector), but once synchronized to split the event again into separate events.

a. to prevent an event consumer from accessing a store until a semaphore has been set. Once set the event consumer can see the store but has no interest in the semaphore

   STORE -> CLX -> SPX -> STORE -> MTHD

   CSM    ->

b. two methods each read a (separate) data store, however we want them to wait until both are ready.

   STORE A -> CLX -> SPX -> STORE A -> MTHD A

   STORE B ->                  -> STORE B -> MTHD B

State

State data is information that describes the current setup of a Method. This data needs to be preserved so that the data is reloaded next time the Method runs. Since CLIP Methods can be run on any computer on the network engaged in the application, CLIP has to manage the data and ensure that it is copied to the correct machine before the Method is run and collected again afterwards.

Since copying state data around a system can reduce system performance, so users should keep State data to a minimum (preferably empty). When Methods simply require a memory area for performing calculations but do not need to preserve the results for each invocation it should use Workspace.

State and Workspace are allocated from the CLIP memory allocation and managed by CLiP.

Store

A Store is an object that holds user defined data and controls access to it.

CLIP provides two flavors of Store object:

Transient Store : Holds data that has not been read or is currently being read. Once all readers have finished with the data the memory is released for reuse. Readers are only allowed access to the once (unless they make an explicit multi-read request). Transient stores are multi-buffered, with each writer writing to a separate buffer. Data is never copied between buffers.

Arbitrated Store: Holds persistent data. Data will exist until it is overwritten. Readers can make repeated requests for read, each time they will see the latest data. Arbitrated stores are double buffered so a writer can make updates whilst readers are still reading. When opening a buffer for update the contents of the existing buffer are copied to the new buffer before any updates are made.

Task

For the purposes of this document 'task' is a scheduling term and means a finite unit of sequentially executing code. So for example, as each method element becomes runnable (which happens when all of its inputs are ready) it can be scheduled for execution as a single task.

Thread (Thrd)

A CDL Thread object performs a user specified task. Unlike CDL Methods, Threads execute continuously blocking on some event(s) often outside of CLIP control. Because of this they have more in common with System threads than CDL Methods. In fact CDL Threads are abstract interfaces to System Threads, with the added capability of interfacing with other CLiP objects. This allows threads to be fully integrated into the CLIP thread synchronisation management.

Transient Store (Tst)

A CDL Transient Store Object, holds data to be used by CLIP Methods etc. It differs from Arbitrated Stores in that the data is not persistent (ie it is destroyed when it has been read) so that it can only be read once.

A CDL Distributer (Dbx) can be used to generated shared read access to a store data buffer.

Unified Modelling Language (UML)

UML is a general-purpose modeling language that includes a graphical notation used to create an abstract model of a system. There are three basic sets of diagrams, Use Cases, Static Model and Dynamic Model.

Use Cases : describe the system requirements from the users point of view. Ie i do something, it does this, that, then the other. It is useful for generating Test Procedures.

Static Model : describe the system Object structure, how they relate to each other and the interfaces that they each provide.

Dynamic Model : describes how the system behaves. Or at least it shows how data is supposed to pass through the system for each use case.

Some UML tool sets allow these diagrams to be cross linked and to be used to generate code.

In the authors opinion it is the third of these diagrams that is most important in multi-threaded, multi-processor applications, but yet it is the least defined and least understood aspect of UML. Use cases are good for showing how the state of the system is changed and this can be captured in a dynamic model (Eg changing gear on a car). However, complex multi-threaded applications are more like the gear box itself, with many cogs and shifts constantly rotating and inter-meshing. Gear changes simply change the routing of the power through the cogs and shafts.

Visual Programming Language

A Visual Programming Language allows users to 'draw' their program. This program can then be turned into code by a translator.

Visual Programming has the advantage that it is often easier to understand a drawing than a textual description, as the symbols are often more intuitive and doesn't include textual delimiters that are required by code compilers.

Eg C++

class banana : public fruit
{
public:
void eat() { --contents; }
private:
int contents;
};

this can be understood by anyone who understands the C++ syntax and any C++ compiler.

However the following can be understand by anyone who understands english (but not a compiler)

A banana is a type of fruit that requires a specific way of removing the skin to allow someone to eat some of the contents.

You can visualise your own picture. This could be understood by anyone whose seen a banana.

Visual Programming Languages often get a bad press because, they often require lots of code to be generated, which is slow and not very efficient (as the translator has to generate fairly generic code). Invariably the generated code still has to be handcrafted by the user, which means that the files can no longer be auto-generated or auto-generated files overwrite the modified one, or the generated file is littered with special text saying "do not modify this bit", or "put your changes here". Quite often the code can be modified without reference to the visualization tool, thus the drawing no longer defines the code. Although regenerating the drawing from the code is possible, many features of the drawing (specific to the drawing but not the code) cannot be Eg. the code states that a feature exists but not where to place it on the screen, this is important when objects are linked.

However, as Visual Programming tools become more mature many of these problems can be overcome providing a fast easy to understand description of the application.

Workspace

Workspace is an area of memory allocated to each Method, Thread, Callback Function and Circuit, that can be utilised to perform calculations. Although this memory is allocated once (on initialization) and preserved it does not follow the Method when it is executed on another machine (unlike State). Thus when a Method is re-executed on a machine some time after the previous execution the workspace will contain the data written from that execution, and not from any intervening executions.

Thus Workspace can contain two types of memory: Constants that are set on initialization and NEVER changed, and scratchpad memory is reinitialized on each execution. Data that must be preserved between executions (except constants) should be put in State (or a store).

State and Workspace are allocated from the CLIP memory allocation and managed by CLiP.

Blueprint Help	Send comments on this topic.
Glossary of Terms